Nguyên lý của các dạng thức thiết kế đã bị phê bình bởi một số lãnh vực của khoa học máy tính.

Nhắm tới sai vấn đề

Điều cần thiết cho các dạng thức kết quả từ việc sử dụng các ngôn ngữ máy tính hay các kĩ thuật thiếu khả năng trườu tượng. Bằng ý tưởng "nhân tử hóa", một nguyên lý không nên được sao chép, mà tốt hơn nên là tham chiếu. Nhưng nếu vật nào đó được tham chiếu thay vì sao chép thì sẽ không có "dạng thức" để đánh nhãn và phân loại. (Paul Graham viết trong bản luận văn Revenge of the Nerds[3] (tức là "sự trả thù của những kẻ kỹ tài"):

This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough— often that I'm generating by hand the expansions of some macro that I need to write.

dịch: Thực nghiệm này không những được thông dụng mà còn được khoa học hoá. Chẳng hạn, trong thế giới OO bạn nghe một ý tưởng về các "dạng thức". Tôi tán thán nếu các dạng thức này đôi khi không phải là bằng chứng của trường hợp (c), trình dịch bằng người, trong công việc. Khi tôi thấy các dạng thức trong các chương trình của mình tôi xem đó là dấu hiệu của sự cố. Hình dáng của mt chương trình chỉ nên phản ảnh vấn đề nó cần giải quyết. Mọi sự chính quy trong mã là dấu hiệu, mà ít nhất đối với tôi, là tôi đang sử dụng những sự trừu tượng mà chúng thường không đủ mạnh đến nỗi tôi đang tạo ra bằng tay các sự mở rộng của các macro mà tôi cần phải viết.

Peter Norvig cho một bàn cãi tương tự cho rằng 16 trong 23 dạng thức trong cuốn Design Patterns ("Các Dạng thức Thiết kế") (mà chủ yếu tập trung trong C++) là đơn giản và loại bỏ được (qua việc hỗ trợ ngôn ngữ trực tiếp) trong Lisp hay trong Dylan[4].

Các bàn cãi xa hơn được tìm thấy trong bài Portland Pattern Repository[5][6].

Thiếu các nền tảng chuẩn

Sự nghiên cứu về các dạng thức thiết kế đã trởo nên quá "đặc ứng" (ad hoc), và một số người cho rằng nguyên lý này cần được chuẩn hóa nhiều hơn. Tại OOPSLA 1999, Gang of Four với sự cồng tác đã đồng thanh chống lại màn xử án[7], trong đó, họ là những người trách nhiệm chính với các tội phạm chống lại khoa học máy tính. Họ đã bị kết án bởi 2/3 của bồi thẩm đoàn[8]. Một số người cảm thấy rằng sự ảnh hưởng từ lý thuyết tương đối có thể giúp họ tốt hơn là xác định, nghiên cứu, hay chuẩn hoá các dạng thức[cần dẫn nguồn].

Dẫn tới các lời giải không hiệu quả

Ý tưởng của một dạng thức thiết kế là một nỗ lực để chuẩn hóa cái mà đã được chấp nhận là các thực nghiệm tốt nhất. Trong nguyên tắc, điều này có thể dường như có ích, nhưng trong thực tế, nó thường dẫn tới kết quả trong sự trùng lặp mã một cách không cần thiết. Hầu như luôn luôn là có một lời giải hiệu quả để sử dụng cho sự thiết lập có tính nhân tố tốt đẹp hơn là một dạng thức thiết kế "chỉ vừa đủ tốt".

Nguyên lý cũ và hiển nhiên

Từ khi bắt đầu, các nguyên lý khoa học máy tính đã được đặt tên (như là truy ngược, backtrackting, hay là cây AVL) và được hồ sơ hoá. Các dạng thức như là được giới thiệu trong cuốn Design Patterns được liên hệ đến các hướng dẫn và các nguyên lý liên hệ . Trong ngành thiết kế cũng đã có các ngành dùng cho tái dụng các cấu trúc thiết kế ( Lưu trữ 2006-08-28 tại Wayback Machine).